Optimized session management for fast session failover and load balancing

ABSTRACT

A system and method of improving session management to facilitate failover and load balancing conditions. During the session, session data is segregated into a first set of core/non-derivable data and a second subset of data that can be derived from the core data. The core data is persistently stored. When a failover condition occurs, the recovering system is provided access to the core data to permit recreation of the session.

BACKGROUND OF THE INVENTION

Embodiments of the invention relate to session management. Morespecifically, embodiments of the invention relate to session managementduring failover and migration of sessions between servers in a loadbalancing situation.

BACKGROUND

The term, “session” commonly refers to data representing an interactionbetween a client and a server. Another common term referring to the samekind of data is “conversational state” because the session comprises thestate that was created on the server due to the conversation betweenclient and server. Different session concepts are used in practice withthe HttpSession of Java Servlets as one important example. While theJava Servlet concept for sessions is flat, having no hierarchy insidethe session data, the web based SAP WebDynpro sessions can havedifferent scopes building a hierarchy of sessions. The session data isnormally associated with one particular user accessing the applicationon the server via the client.

Sessions are commonly implemented using a token that is transportedbetween the client and the server with each request. The token forexample may be a hyper text transfer protocol (HTTP) cookie or theusername of the user using the client. A token is used as a key for anassociative array (for example, java.util.Map) that contains the sessiondata. The data is typically organized as name/value pairs with the nameoften restricted to a string and the value allowing nearly any kind ofobject. The data stored in the session is required to serve requestsfrom the corresponding client. If the data is not available the clientcannot be served. This makes the session data very important andnecessitates additional mechanisms in case of server problems. One kindof problem a server may encounter is software or hardware errors.Another is high load situations. In either case, the server may not beable to serve requests from the clients for which it is holding thesession data. Therefore, the requests must be served by another server,but this requires a mechanism to move the session data to the newserver. A common term for this movement in case of an error on theserver is called “failover” but the same argument applies to high loadand therefore “load-balancing” situations. To support failover, someimplementations require the session data, i.e. the objects in thesession, to be serializable. Movement of sessions between servers orserver nodes always requires serialization, copying or cloning ofexisting session data. The time required to perform the failover dependsheavily on the size of the session. In existing systems, large sessionsizes often preclude failover operations in productive environments.

SUMMARY OF THE INVENTION

A system and method of improving session management to facilitatefailover is disclosed. During the session, session data is segregatedinto a first set of core/non-derivable data and a second subset of datathat can be derived from the core data. The core data is stored outsidethe server process. When a failover condition occurs, the recoveringsystem is provided access to the core data to permit recreation of thesession.

BRIEF DESCRIPTION OF DRAWINGS

The invention is illustrated by way of example and not by way oflimitation in the figures of the accompanying drawings in which likereferences indicate similar elements. It should be noted that referencesto “an” or “one” embodiment in this disclosure are not necessarily tothe same embodiment, and such references mean at least one.

FIG. 1 is a block diagram of a logical view of a system architectureaccording to one embodiment of the invention.

FIG. 2A is a block diagram of a portion of system of one embodiment ofthe invention.

FIG. 2B is a block diagram of one embodiment of a portion of the systemof an alternate embodiment of the invention.

FIG. 3A is a flow diagram of operation in an application according toone embodiment of the invention.

FIG. 3B is a flow diagram of operation in the session manager accordingto one embodiment of the invention.

FIG. 3C is a flow diagram of operation in an alternative application inresponse to a failover condition.

DETAILED DESCRIPTION

FIG. 1 is a block diagram of a logical view of a system architectureaccording to one embodiment of the invention. The architecture mayinclude a plurality of application server instances such as, instance101. The application server instance 101 includes a group of workernodes 112-114, and a dispatcher 111. Where a plurality of homogenousinterconnected server instances exist, they are referred to as a“cluster.” Although the following description will focus solely oninstance 101 for the purpose of explanation, the same principles applyto other instances (not shown) within a cluster.

The worker nodes 112-114 within instance 101 provide the business and/orpresentation logic for the network applications supported by the system.In case of a Java based application server, each worker contains a Javavirtual machine (represented as virtual machines 121-123 in FIG. 1) toexecute the business logic and to store the associated data. In case ofnon Java based server the architecture may not contain virtual machines.In one embodiment, the dispatcher 111 distributes service requests fromclients to one or more of the worker nodes 112-114 using request queuesstored in shared memory 140. The request handler 111 fills the queueswith client requests and the worker nodes 112-114 consume the requestsfrom each of their respective queues. In another embodiment, requestscan be distributed to the worker nodes directly from queues maintainedin the dispatcher's memory.

The worker nodes 112-114 may be Java 2 Enterprise Edition (“J2EE”)worker nodes which support Enterprise Java Bean (“EJB”) components ofEJB containers (at the business layer) and Servlets and Java ServerPages (“JSP”) (at the presentation layer). In one embodiment, thevirtual machines 121-125 implement the Java 2 Standard EditionSpecification 1.3, published Jul. 27, 2001 or subsequent versionsthereof (the J2SE Standard). It should be noted, however, that theembodiments of the invention described herein may be implemented in thecontext of various different software platforms including, by way ofexample, Microsoft.NET platforms and/or the Advanced BusinessApplication Programming (“ABAP”) platforms developed by SAP AG, ofWalldorf, Germany.

In one embodiment, a session manager 130 is executed within the instance101. The session manager 130 includes the program code, interfaces anddata for implementing the various session management techniquesdescribed herein. The session manager 130 stores data in a sessioncontext responsive to an application. Traditionally, a great amount ofthe data in the session context is used like a cache for a particularuser. While much of the data is not truly essential to handle userrequest, recreating that data for each request from scratch is tooexpensive in terms of CPU usage. By segregating the essential (core)data from the nonessential data, faster failover can be achieved. Asused herein, “core” when modifying data refers to data that is nototherwise derivable by the application or the system from other entriesin the session. This data is essential to continue processing userrequests. For example, user entered data not persisted elsewhere in thesystem would be core data. If the data is derivable from the core dataor elsewhere in the system, it is referred to herein interchangeably ascache session data or derivable data.

One embodiment of the session manager 130 manages session objects withsession domains as described in detail below. Generally, session manager130 receives requests to store data in the session from the applicationthat is running on the worker nodes 112-114. An application within theapplication server may provide a hint to the session manager 130 whetherthe stored data contains or does not contain core data. In oneembodiment, the session manager 130 may include two methods: a coremethod and a cache method 162 to store core and cache data respectively.“Core method” refers to a method used to process the core data to createa core session object. “Cache method” refers to a method to processcache session or derivable data. The core method creates a core sessionobject to retain the core data and adds core data to that object asadditional core data is received. In one embodiment, the hint may takethe form of calling the respective method to handle the request.

In one embodiment, the core session object is persisted in shared memory140 using for example Shared Closures. In another embodiment, the coresession object is persisted to persistent storage 145. In variousembodiments, core session may be persisted to a database or to a filesystem. The cache method 162 handles the derivable data also referred toas the cache session data. This data may be managed as a separate objectfrom the core session object. In one embodiment, the data is merelymaintained in the local cache 164 of the server handling the session. Inanother embodiment, the cache data may be retained in shared memory, butis not passed/copied to a receiving server in the event of failover andmay in fact be lost during the failure condition necessitating failover.The merits of this latter embodiment depend on the cost, e.g., in termsof CPU time, of copying from shared memory as opposed to recreating thesession from the core session object.

FIG. 2A is a block diagram of a portion of system of one embodiment ofthe invention. A VM 121 includes an application 202 engaged in thesession. Application 202 issues session requests constituting eithercore session requests or other session requests. In the shownembodiment, core session requests take the form of a method call to thecore method 160 and other method requests include a method calls tocache method 162. In this manner, the session manager 130 is instantlyaware of whether the request includes core data or not. Calls to thecore method 160 result in the corresponding data being retained as partof core session object 170. Calls to cache method 162 results in thedata being retained in cache session object 210. Session manager 130manages both cache session object 210 and core session object 170 forthe session. Cache session object 216 may be managed in local cache 164of VM 121 while core session object 170 is managed in shared memory.However, in the event of a failure condition (depicted in the drawing asX 230 representing failure of the VM 121), the cache session object 210is discarded (in practice it may have been lost in the failure event,e.g., because VM 121 fails and local cache 164 is lost) and the coresession object 170 is passed to application 202 running in VM 122.Session manager 130 may pass the core session object 130 or a handle tothe object to the application that is to take over the session. In oneembodiment, at start up, the various applications, e.g., 202 that usethe session manager 130 registers the logic that can recreate thesession with the session manager 130. In such an embodiment, informationrequired to recreate a cache session from the core session object ispart of the business logic. In one embodiment, application 202 may calla recreate method in application programming interface (API) 204. API204 will then derive/recreate the cache session data (which is definedto be derivable from the core session data). Application 202 and VM 122can continue the session at the point where failover occurred. In analternative embodiment application 202 may recreate the data of thecache session itself.

FIG. 2B is a block diagram of one embodiment of a portion of the systemof an alternative embodiment of the invention. In this embodiment,application 202 sends tagged session requests to session manager 130.Session manager 130 includes a request interpreter 206 which identifies(from the tag) which of the session requests include core data in whichthe session requests include cache session data. The data is thensegregated into the corresponding core session object 170 or cachesession object 210 respectively. These objects may be managed separatelyis shared memory 140 and local cache 164 respectively. Failover may behandled as described in connection with the embodiment of FIG. 2A.

FIG. 3A is a flow diagram of operation in an application according toone embodiment of the invention. The application initiates a session atblock 300. A determination is made at block 302 whether the request tobe sent to the session manager includes core data. Request from theapplication to the session manager should be distinguished from requestsbetween the client and the server. Unless otherwise indicated, “request”as used herein refers to a request between the application and sessionmanager. “Client request” refers to requests between the client and theserver. If the request to be sent includes core data, a hint is provided318. In various embodiments, it can be tagged as including core data atblock 304 or an explicit call to a core method may be made at block 306.If the request to the session manager does not include core data, a hintmay be provided 318. It may be tagged at block 310 or a call to a cachemethod may be made at block 308. As a general matter, an embodiment ofthe invention will generally include either blocks 304 and 310 or blocks306 and 308. These represent only a couple examples of how theapplication may hint to the session manager which session requestsinclude core data. After the hint the request is sent through thesession manager at block 311. A determination is made by the applicationat block 312 whether the session has ended. If it has not, the nextrequest is processed beginning at block 314. In some embodiments,between a pair of requests to the session manager, there may be anynumber, though usually one, client request(s). Client requests do notdirectly impact the flow discussed herein.

FIG. 3B is a flow diagram of operation in the session manager accordingto one embodiment of the invention. At block 320, a session begins. Atblock 322, a determination is made if an incoming request from theapplication includes core data. This determination may be the result ofinterpreting a hint provided by the application. In various embodiments,a hint may be an explicit call to, e.g., a core method or may be taggingthe request is containing (not containing) core data. If the requestdoes not include core data, the data may be retained in a local cache orotherwise managed as a separate object at block 326. If the request isdetermined to include core data, the data may be persistently stored incore session object at block 328. This may result in the core sessionobject being persisted to a database, retained in a file system orretained in shared memory. As used herein, persistent storage of thecore session object means that it is stored persistently relative to afailure of the server process handling the session, e.g., it is storedoutside the server process such that a crash of the server node does notresult in a loss of the core session object. By defaulting to core valuewhere no hint is present, backward compatibility is inherentlymaintained because all requests will be treated as core data and thecore session object will include all session data.

At block 330, a determination is made and a failover is necessary. Thesession manager passes the core session objection to an alternateinstance of the application likely residing on a separate applicationserver at block 332. In some embodiments, the object may be passed to anapplication in a separate instance within the cluster. At block 334, adetermination is made if the session has ended. If it has not, the nextreceived request begins processing at block 336.

FIG. 3C is a flow diagram of operation in an alternative application inresponse to a failover condition. Application receives the core sessionobject at block 342 from the session manager. At block 344, theapplication recreates the cache session data. In one embodiment, an API,including a recreation method, may be made available to the application.In such embodiment, the application calls the recreation method, whichwill perform the recreation/derivation of cache session data. Thealternate application then continues the session at the point thefailover occurred as shown in FIG. 3A.

Elements of embodiments may also be provided as a machine-readablemedium for storing the machine-executable instructions. Themachine-readable medium may include, but is not limited to, flashmemory, optical disks, CD-ROMs, DVD ROMs, RAMs, EPROMs, EEPROMs,magnetic or optical cards, propagation media or other type ofmachine-readable media suitable for storing electronic instructions. Forexample, embodiments of the invention may be downloaded as a computerprogram which may be transferred from a remote computer (e.g., a server)to a requesting computer (e.g., a client) by way of data signalsembodied in a carrier wave or other propagation medium via acommunication link (e.g., a modem or network connection).

It should be appreciated that reference throughout this specification to“one embodiment” or “an embodiment” means that a particular feature,structure or characteristic described in connection with the embodimentis included in at least one embodiment of the present invention.Therefore, it is emphasized and should be appreciated that two or morereferences to “an embodiment” or “one embodiment” or “an alternativeembodiment” in various portions of this specification are notnecessarily all referring to the same embodiment. Furthermore, theparticular features, structures or characteristics may be combined assuitable in one or more embodiments of the invention.

In the foregoing specification, the invention has been described withreference to specific embodiments thereof. It will, however, be evidentthat various modifications and changes can be made thereto withoutdeparting from the broader spirit and scope of the invention as setforth in the appended claims. The specification and drawings are,accordingly, to be regarded in an illustrative rather than a restrictivesense.

1. A method comprising: segregating data in a session into a first setand a second set; storing the first set outside a first server process;and providing access by an application within a second server process tothe first set responsive to one of a failover or a load balancingcondition.
 2. The method of claim 1 further comprising: reconstructingfrom the application the second set from the first set.
 3. The method ofclaim 1 further comprising: hinting to a session manager which datashould be in the first set and which data should be in the second set.4. The method of claim 3 wherein hinting comprises: calling a firstmethod in the session manager from the application if data should be inthe first set; and calling a second method in the session manager fromthe application if data should be in the second set.
 5. The method ofclaim 3 wherein hinting comprises: tagging data from the application asderivable or non-derivable.
 6. The method of claim 1 wherein providingcomprises: passing an object containing the first set to theapplication.
 7. A machine-accessible medium containing instructions thatwhen executed cause a machine to: segregate data in a session into afirst set and a second set; store the first set outside a first serverprocess; and provide access by an application within a second serverprocess to the first set responsive to one of a failover or loadbalancing condition.
 8. The machine accessible medium of claim 7,further comprising instructions causing the machine to: reconstruct fromthe application the second set from the first set.
 9. The machineaccessible medium of claim 7, further comprising instructions causingthe machine to: hint to a session manager which data should be in thefirst set and which data should be in the second set.
 10. The machineaccessible medium of claim 9, wherein instructions causing the machineto hint includes instructions causing the machine to: call a firstmethod in the session manager from the application if data should be inthe first set; and call a second method in the session manager from theapplication if data should be in the second set.
 11. The machineaccessible medium of claim 9, wherein instructions causing the machineto hint includes instructions causing the machine to: tag data from theapplication as derivable or non-derivable.
 12. The machine accessiblemedium of claim 7, wherein instructions causing the machine to provideincludes instructions causing the machine to: pass an object containingthe first set to the application.
 13. A system comprising: a persistentstorage unit; an execution environment having a session; a sessionmanage to store a subset of session data outside a first server processof the execution environment wherein an application indicates to thesession manager what session data should be in the subset.
 14. Thesystem of claim 13, wherein the execution environment comprises: avirtual machine.
 15. The system of claim 13 wherein the persistentstorage comprises one of: a database, a file system, or a SharedClosure.
 16. The system of claim 13 wherein the session manager providesthe application access to the subset responsive to a failover conditionand the application transparently recreates the session from the subset.17. The system of claim 13 wherein the session manager comprises: afirst method to be called by the application if a request contains datain the subset; and a second method to be called by the application if arequest does not contain data in the subset.
 18. An apparatuscomprising: means for segregating session data into a core subset and anon-core subset; and means for passing only the core subset to asubstitute application in response to one of a failover or loadbalancing condition.
 19. The apparatus of claim 18 further comprising:means for recreating the non-cores subset from the core subset.
 20. Theapparatus of claim 18 further comprising: means for hinting if a sessionrequest includes core data.